Перейти к основному содержимому

2.04. Веб-приложение

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВНЕ ДЛЯ НОВИЧКОВВ РАЗРАБОТКЕ
Всем

Веб-приложение​

Понятие веб-приложение часто употребляется в профессиональной среде как данность, однако его точное определение требует чёткого разграничения от смежных категорий — в первую очередь, от веб-сайта. Такое разграничение не является формальностью: оно отражает фундаментальные различия в архитектуре, поведении и целях использования. Чтобы понять, что именно делает программу веб-приложением, необходимо последовательно рассмотреть эволюцию веб-ресурсов — от статичных страниц к интерактивным системам.

Веб-сайт и веб-приложение​

С исторической точки зрения, ранний Всемирный веб состоял из статических веб-сайтов — совокупностей HTML-файлов, расположенных на сервере и отдаваемых браузеру без какой-либо предварительной обработки. Пользователь открывал страницу, получал готовый контент и переходил по ссылкам, инициируя загрузку новых файлов. Такое поведение не отличалось от просмотра документов в локальной файловой системе, за исключением того, что файлы запрашивались через сеть.

Веб-сайт в широком смысле — это информационный ресурс, главная задача которого — представление сведений. Его содержание может изменяться, но изменения происходят до момента запроса со стороны пользователя: администратор или CMS-система генерирует новый HTML-файл, и только затем он становится доступен для скачивания. Примерами являются корпоративные сайты, лендинги, блоги на платформах вроде WordPress в режиме кэширования или статической генерации.

Веб-приложение же определяется не столько содержанием, сколько поведением. Оно представляет собой программную систему, реализующую логику, принятие решений, хранение и обработку состояния — зачастую персонализированного. Пользователь не просто читает информацию, а взаимодействует с системой: отправляет данные, получает персональные результаты, изменяет внутреннее состояние приложения (например, создаёт запись в календаре или редактирует документ). Ключевой признак — динамическое обновление интерфейса без полной перезагрузки страницы, реализуемое средствами JavaScript и асинхронных сетевых запросов.

Следует подчеркнуть: граница между сайтом и приложением не всегда резка. Многие современные сайты содержат элементы приложений — формы авторизации, интерактивные карты, чаты. Однако системообразующим критерием остаётся степень централизации логики: если основная бизнес-логика, управление состоянием и обработка данных происходят на стороне клиента с постоянной синхронизацией со службами, — перед нами веб-приложение. Если же клиентская часть ограничена представлением, а вся логика сосредоточена на сервере, генерирующем HTML при каждом запросе, — это сайт, даже если он использует JavaScript для анимаций или валидации форм.

Статический и динамический веб-сайт​

Термины статический и динамический применяются к сайтам (и, по аналогии, к приложениям) в зависимости от того, когда и кем формируется конечный HTML, который получает браузер.

Статический сайт — это набор предварительно сгенерированных HTML-, CSS- и JS-файлов. Они создаются один раз (вручную или с помощью генераторов статических сайтов, таких как Gatsby, Hugo, Docusaurus), размещаются на веб-сервере (например, Nginx или CDN), и при каждом запросе отдаются «как есть», без изменения. Преимущества: высокая скорость отдачи, минимальные требования к серверу, безопасность (отсутствие исполняемой серверной логики), простота развёртывания. Недостаток — невозможность персонализации и динамического содержания без привлечения внешних API.

Динамический сайт генерирует HTML в момент запроса. Сервер получает HTTP-запрос, запускает серверную программу (например, на PHP, Python, Node.js, Java), которая может:

  • обратиться к базе данных;
  • прочитать куки или заголовки авторизации;
  • выполнить бизнес-логику;
  • сформировать HTML на основе шаблонов и полученных данных;
  • вернуть результат браузеру.

Такой подход позволяет отображать разный контент разным пользователям (например, личный кабинет), но требует более сложной инфраструктуры и несёт риски, связанные с производительностью и безопасностью (например, SQL-инъекции). Отметим, что динамический сайт не обязательно является веб-приложением: если после генерации HTML весь дальнейший контроль передаётся браузеру, а интерфейс остаётся «страничным» (переход по ссылкам = новая загрузка), — это сайт с динамическим контентом, но без интерактивной логики на стороне клиента.

Клиент​

В контексте веб-приложений термин клиент обозначает не физическое лицо, а среду выполнения, которая инициирует запросы к серверу и обрабатывает полученные данные. В подавляющем большинстве случаев клиентом выступает веб-браузер — программное приложение (Chrome, Firefox, Safari и др.), реализующее стандарты HTML, CSS и JavaScript.

Браузер — это не просто «окно в интернет», а сложная платформа, объединяющая несколько независимых компонентов:

  • движок рендеринга (например, Blink в Chrome, Gecko в Firefox), отвечающий за парсинг HTML и CSS, построение DOM- и CSSOM-деревьев, создание дерева отрисовки (render tree), компоновку (layout) и вывод пикселей на экран;
  • движок выполнения JavaScript (например, V8 в Chrome и Node.js, SpiderMonkey в Firefox), компилирующий и исполняющий JS-код в изолированной песочнице (виртуальной машине);
  • механизмы хранения (Cookies, LocalStorage, SessionStorage, IndexedDB), обеспечивающие сохранение состояния между сессиями;
  • сетевой стек, управляющий HTTP(S)-запросами, кэшированием, соединениями по WebSocket и другими протоколами;
  • безопасностная модель, реализующая политики CORS, CSP, SameSite, sandbox и др.

Важно понимать, что клиент в веб-приложении — это не пассивный получатель, а активный участник вычислений. Современные фронтенд-фреймворки (React, Angular, Vue) фактически превращают браузер в полноценную среду выполнения, где происходит управление состоянием приложения, маршрутизация, валидация данных, кэширование запросов и даже частичное выполнение бизнес-логики. Сервер при этом часто деградирует до роли провайдера данных (через API), а не генератора интерфейса.

Консоль разработчика​

Для разработки и диагностики веб-приложений незаменимым инструментом является Консоль разработчика (Developer Tools, сокращённо DevTools) — встроенная панель инструментов браузера, вызываемая нажатием клавиши F12 или сочетанием Ctrl+Shift+I (Cmd+Option+I на macOS). Это не «консоль» в узком смысле (терминал для ввода команд), а целый набор модулей, каждый из которых отвечает за определённый аспект работы клиентской части.

DevTools — это основное окно, через которое разработчик получает доступ к внутренним структурам браузера. Её использование не ограничивается отладкой: она применяется для профилирования производительности, анализа сетевого трафика, инспекции безопасности, эмуляции устройств и даже аудита доступности. Ниже рассматривается назначение ключевых вкладок, с акцентом на их роль в понимании работы веб-приложения.

Elements​

Вкладка Elements отображает текущее состояние DOM-дерева — структурированное представление HTML-документа после выполнения всех скриптов и динамических изменений. Здесь можно:

  • просматривать и временно редактировать HTML-элементы (внесённые изменения не сохраняются на сервере, но позволяют проверить гипотезы макета);
  • исследовать применённые CSS-правила, отслеживать наследование и каскад, отключать стили для анализа;
  • наблюдать за псевдоэлементами (::before, ::after), состояниями (:hover, :focus);
  • измерять размеры блоков, отступов, границ в реальном времени (Box Model);
  • изменять атрибуты элементов (например, disabled, checked, src).

Эта вкладка демонстрирует фундаментальный принцип: DOM — это живая модель, отличная от исходного HTML. JS может создавать, удалять, перемещать узлы, а CSS может скрывать или визуально трансформировать их, не затрагивая разметку. Именно в Elements можно увидеть результат работы фронтенд-фреймворка — например, как React заменяет части дерева при обновлении состояния.

Console​

Вкладка Console выполняет три функции:

  1. Логирование ошибок и предупреждений — браузер автоматически выводит сведения о синтаксических ошибках в JS, проблемах с CORS, ненайденных ресурсах, исключениях в коде;
  2. Интерактивное выполнение JavaScript — любая команда, введённая в консоль, исполняется в контексте текущей вкладки. Можно вызывать функции, читать/менять переменные, исследовать глобальные объекты (window, document, localStorage);
  3. Просмотр логов приложения — разработчики явно выводят информацию через console.log(), console.warn(), console.error() для отслеживания потока управления.

Console — первый индикатор работоспособности клиентской части. Пустая консоль без ошибок — необходимое (но не достаточное) условие корректной работы.

Sources​

Вкладка Sources предназначена для отладки JavaScript. Она отображает дерево загруженных скриптов (включая минифицированные и сгенерированные), позволяет:

  • устанавливать точки останова (breakpoints) по строкам кода;
  • исследовать стек вызовов;
  • просматривать и изменять локальные и глобальные переменные во время паузы;
  • выполнять шаговое выполнение (step into, step over);
  • работать с source maps — отображать минифицированный JS в виде исходного кода (например, TypeScript → JS).

В среде веб-приложения, где значительная часть логики сосредоточена на клиенте, Sources становится основным инструментом для проверки корректности обработки событий, управления состоянием и работы с API.

Network​

Вкладка Network фиксирует все сетевые запросы, инициированные страницей: HTML, CSS, JS, изображения, шрифты, а также XHR/fetch-запросы к API. Для каждого запроса отображаются:

  • HTTP-метод (GET, POST и др.);
  • URL и параметры;
  • заголовки запроса и ответа;
  • тело запроса и ответа (в том числе JSON);
  • статус-код (200, 404, 500 и т.д.);
  • время загрузки (включая ожидание DNS, TCP-handshake, TLS, ожидание сервера, получение данных);
  • инициатор (какой скрипт или элемент вызвал запрос).

Эта вкладка критически важна для понимания взаимодействия клиента и сервера. Например, при нажатии кнопки «Сохранить» в веб-приложении можно увидеть, какой именно POST-запрос отправляется, какие данные передаются, какой статус возвращает сервер — и, при необходимости, воспроизвести запрос вручную (через «Copy as cURL»).

Performance и Application​

Performance позволяет записывать сессию взаимодействия с интерфейсом и анализировать временные затраты на этапы: синтаксический анализ (parsing), выполнение JS, перерисовку (repaint), перекомпоновку (reflow), композитинг. Это необходимо для выявления «тормозов» и оптимизации UX.

Application даёт доступ к клиентским механизмам хранения: Cookies, LocalStorage, SessionStorage, IndexedDB, кэш Service Worker. Здесь можно просматривать, редактировать и удалять сохранённые данные — что особенно полезно при отладке сессий, авторизации или офлайн-режимов.

Архитектура и жизненный цикл веб-приложения​

Понимание веб-приложения как единого целого невозможно без анализа его компонентной структуры и последовательности событий, происходящих при взаимодействии пользователя с системой. Веб-приложение — это распределённая система, где логика, данные и представление разнесены по разным средам исполнения, соединённые стандартными протоколами и интерфейсами. Его работа строится не на мгновенной реакции, а на строго упорядоченной цепи преобразований: от текста URL до отрисовки пикселей, от нажатия кнопки до сохранения записи в базе данных.

Компоненты веб-приложения: фронтенд, бэкенд, база данных, API​

Современное веб-приложение состоит из четырёх основных логических слоёв, каждый из которых имеет чёткую ответственность и границы взаимодействия.

Фронтенд (клиентская часть) — это программный код, исполняемый в браузере пользователя. Он включает:

  • разметку (HTML), задающую структуру документа;
  • стили (CSS), определяющие визуальное оформление и поведение при взаимодействии;
  • логику (JavaScript), управляющую динамикой интерфейса, обработкой событий, валидацией, маршрутизацией и сетевыми запросами.

Фронтенд отвечает за восприятие приложения пользователем: от скорости первоначальной загрузки до плавности анимаций и мгновенности реакции на действия. Он не хранит основные данные и не принимает окончательных решений по безопасности — его роль сводится к представлению и промежуточной обработке. Однако именно фронтенд формирует ощущение «живости» системы: обновление списка задач без перезагрузки, мгновенная проверка доступности логина, drag-and-drop перемещение элементов — всё это реализуется на клиенте.

Бэкенд (серверная часть) — это программное обеспечение, размещённое на выделенном сервере или в облачной инфраструктуре, доступное по сетевому адресу. Его задачи:

  • приём и аутентификация входящих запросов;
  • выполнение бизнес-логики (расчёт итогов, применение правил, проверка условий);
  • взаимодействие с системами хранения (базами данных, файловыми хранилищами, кэшами);
  • формирование и отправка ответов в стандартизированном формате.

Бэкенд обеспечивает консистентность и надёжность: он гарантирует, что операции, необратимые или требующие контроля (платёж, удаление аккаунта, изменение прав доступа), выполняются корректно и атомарно. Архитектура бэкенда может варьироваться от монолита до микросервисов, но в любом случае он изолирован от прямого доступа клиента — взаимодействие строго опосредовано.

База данных — постоянное хранилище структурированной информации. В контексте веб-приложений это, как правило, реляционные (PostgreSQL, MySQL) или документо-ориентированные (MongoDB) СУБД, хотя возможны и другие варианты (графовые, временные, full-text). База данных обеспечивает:

  • долговременное хранение с гарантиями целостности (ACID-транзакции);
  • эффективный поиск и выборку по индексам;
  • управление параллельным доступом;
  • репликацию и резервное копирование.

Ключевое ограничение: база данных никогда не доступна напрямую из браузера. Весь доступ строго контролируется бэкендом, который выступает в роли шлюза, проверяющего права и валидирующего запросы. Прямое подключение клиента к СУБД — грубейшая архитектурная и security-ошибка.

API (Application Programming Interface) — это контракт между фронтендом и бэкендом. На практике это совокупность HTTP-эндпоинтов (URL-путей), каждый из которых реализует определённую операцию и ожидает данные в заданном формате (обычно JSON). API определяет:

  • какие действия доступны (получить список, создать запись, обновить статус);
  • какие параметры требуются (идентификатор, токен, тело запроса);
  • какой формат ответа возвращается (успех/ошибка, данные, метаинформация);
  • какие HTTP-коды используются для семантической индикации результата (200 OK, 201 Created, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 500 Internal Error).

API — это не технология, а принцип организации взаимодействия. Он позволяет фронтенду и бэкенду развиваться независимо: изменения в UI не требуют переписывания серверной логики, если контракт API сохраняется. REST (Representational State Transfer) — наиболее распространённый стиль проектирования API, однако существуют и другие (GraphQL, gRPC over HTTP/2, RPC-style).

Таким образом, веб-приложение — это не «сайт плюс JavaScript», а оркестровка изолированных компонентов, каждый из которых отвечает за свою область ответственности, а их согласованная работа обеспечивается через стандартизированные интерфейсы и протоколы.

Последовательность инициализации: от URL до интерактивного интерфейса​

Чтобы проиллюстрировать взаимодействие компонентов, рассмотрим типичный сценарий — открытие веб-приложения в браузере. Возьмём в качестве примера URL https://app.example.com/tasks. Процесс можно разбить на семь логических этапов.

Этап 1. DNS-разрешение и установка соединения
Браузер извлекает доменное имя (app.example.com) из URL и обращается к DNS-серверу для получения IP-адреса сервера. После получения адреса устанавливается TCP-соединение (трёхэтапное рукопожатие), и при использовании HTTPS — дополнительно TLS-сессия (согласование шифров, проверка сертификата). Только после этого становится возможной передача HTTP-запроса.

Этап 2. Запрос HTML-документа и его получение
Браузер формирует HTTP-запрос GET /tasks, добавляя стандартные заголовки (User-Agent, Accept, Accept-Language, Cookie, если есть). Сервер получает запрос, маршрутизирует его (например, через веб-сервер Nginx к приложению на Node.js), которое, в свою очередь, может:

  • проверить наличие сессии (по куки или заголовку Authorization);
  • извлечь из базы данных список задач пользователя;
  • применить шаблонизатор (например, Handlebars, Thymeleaf) для генерации HTML;
  • вернуть ответ с кодом 200 и телом — разметкой страницы.

В случае SPA (Single-Page Application) сервер часто возвращает один и тот же HTML-файл (index.html) для всех маршрутов, а дальнейшая маршрутизация происходит на клиенте.

Этап 3. Парсинг HTML и построение DOM-дерева
Браузер получает HTML и начинает его последовательную обработку. По мере чтения потока данных он строит DOM-дерево (Document Object Model) — объектное представление структуры документа. Каждый тег становится узлом (node), атрибуты — свойствами узлов, текстовое содержимое — текстовыми узлами. DOM — это не статическая копия HTML: это живая структура, которую JavaScript может изменять в любое время.

Парсинг прерывается при встрече тега <script>. Если скрипт не имеет атрибутов async или defer, браузер приостанавливает построение DOM, загружает и исполняет JS — это называется блокирующим парсингом. Современные приложения стараются минимизировать блокировки, используя асинхронную загрузку критических ресурсов.

Этап 4. Загрузка и обработка CSS. Построение CSSOM
Параллельно с HTML браузер обнаруживает ссылки на таблицы стилей (<link rel="stylesheet">) и начинает их загрузку. CSS обрабатывается отдельно: из текстового файла строится CSSOM (CSS Object Model) — древовидная структура правил, где каждый узел содержит селектор, специфичность и набор деклараций. CSSOM необходим для последующего объединения с DOM.

Важно: CSS является блокирующим ресурсом для рендеринга. Браузер не отрисует видимый контент до тех пор, пока не построит полное CSSOM, даже если DOM уже готов. Это объясняет появление «FOUC» (Flash of Unstyled Content) при некорректной загрузке стилей.

Этап 5. Формирование Render Tree, Layout и Paint
После построения DOM и CSSOM браузер объединяет их в дерево отрисовки (Render Tree). В него входят только видимые узлы (например, элементы со display: none исключаются). Для каждого узла Render Tree вычисляются окончательные CSS-свойства (с учётом наследования и каскада).

Затем запускается Layout (также называемый Reflow): браузер рассчитывает геометрию каждого элемента — координаты, размеры, позиционирование относительно родителей и окна. Это ресурсоёмкая операция, особенно при изменении размеров окна или динамическом добавлении элементов.

После Layout следует Paint (также Rasterization): браузер преобразует геометрические данные в пиксели — заполняет фоны, рисует границы, текст, тени. На этом этапе формируются «слои» (layers), которые затем передаются композитору.

Этап 6. Выполнение JavaScript и инициализация приложения
Как только DOM становится доступен (событие DOMContentLoaded), запускается основной JavaScript-код приложения. Для SPA это означает:

  • инициализацию фреймворка (React, Vue и др.);
  • создание виртуального DOM или реактивных наблюдателей;
  • настройку клиентской маршрутизации (например, через History API);
  • выполнение первого запроса к API для получения данных (например, GET /api/tasks);
  • обработку ответа и рендер интерфейса на основе полученных данных.

Важно: JavaScript может модифицировать DOM и CSSOM в любой момент после их построения. Это приводит к повторным циклам Layout и Paint — например, при обновлении списка задач после получения данных с сервера.

Этап 7. Установление интерактивности
После завершения инициализации приложение переходит в состояние ожидания событий. Пользовательский ввод (клик, ввод текста, прокрутка) генерирует события, которые перехватываются обработчиками (event listeners). Обработчики могут:

  • изменять состояние приложения (например, помечать задачу как выполненную);
  • инициировать асинхронные запросы к API (fetch('/api/tasks/123', { method: 'PATCH', body: JSON.stringify({ done: true }) }));
  • обновлять DOM без перезагрузки страницы (например, через методы фреймворка или element.textContent = …).

Именно на этом этапе проявляется суть веб-приложения: состояние сохраняется в памяти клиента, а синхронизация с сервером происходит прозрачно для пользователя. Браузер не перезагружает страницу — он лишь отправляет данные и частично обновляет интерфейс.

Роль JavaScript в трансформации сайта в приложение​

Статический сайт и веб-приложение используют одни и те же технологии — HTML, CSS, HTTP. Различие вводится JavaScript не количественно («больше кода»), а качественно — через изменение парадигмы управления состоянием.

В традиционном сайте состояние хранится на сервере, и каждый запрос — это переход в новое состояние, выражаемое новым HTML-документом. В веб-приложении состояние реплицируется на клиент: браузер хранит текущий набор данных (например, список задач, фильтры, режим редактирования), и любое действие пользователя локально изменяет это состояние, после чего инициируется асинхронная синхронизация с сервером. Сервер при этом отвечает не HTML-страницей, а данными (обычно JSON), которые клиент использует для обновления своего внутреннего представления.

Такой подход позволяет добиться:

  • мгновенной реакции на действия (нет ожидания загрузки страницы);
  • оффлайн-работы (состояние сохраняется в IndexedDB, запросы ставятся в очередь);
  • сложных интерфейсов (drag-and-drop, редакторы в реальном времени, анимации);
  • повторного использования логики (один и тот же код управляет интерфейсом независимо от маршрута).

Однако он требует строгого контроля над синхронизацией, обработкой конфликтов и откатом операций — задачи, которые ранее решались автоматически за счёт перезагрузки страницы.

Архитектурные модели, безопасность и эволюция веб-приложений​

Определение веб-приложения как интерактивной программы, работающей в браузере, не исчерпывает его многообразия. На практике реализация может сильно различаться в зависимости от выбранной архитектурной модели, требований к безопасности, ограничений инфраструктуры и целевой аудитории. Понимание этих различий необходимо не только для проектирования, но и для корректной диагностики, оценки рисков и выбора инструментов.

Типы веб-приложений​

Существует несколько устоявшихся моделей организации веб-приложений, каждая из которых отражает компромисс между сложностью, производительностью, SEO-дружелюбностью и UX-качеством.

MPA (Multi-Page Application) — классическая модель, унаследованная от статических сайтов. Каждое пользовательское действие, ведущее к изменению состояния (переход по ссылке, отправка формы), инициирует полную перезагрузку страницы. HTML генерируется на сервере, клиентская логика минимальна (валидация, анимации).
Преимущества: простота реализации, естественная поддержка поисковой индексации, низкие требования к клиентскому устройству.
Недостатки: задержки при навигации, дублирование общей разметки (шапка, меню), сложность поддержки сложного состояния (например, многошаговые формы с возвратом).
MPA остаётся актуальной для контентных сайтов, корпоративных порталов, систем, где критична доступность при низкой скорости канала или устаревших браузерах.

SPA (Single-Page Application) — модель, в которой вся клиентская логика и рендеринг сосредоточены в браузере. Сервер отдаёт один HTML-файл (обычно index.html) и набор JS/CSS-ресурсов. После инициализации фронтенд берёт на себя маршрутизацию (через History API: pushState, popstate), управление состоянием и частичное обновление DOM. Данные запрашиваются и отправляются через API.
Преимущества: мгновенная навигация, плавный UX, чёткое разделение зон ответственности (фронтенд — UI, бэкенд — данные), возможность offline-работы.
Недостатки: увеличенный объём первоначальной загрузки, сложность SEO без дополнительных мер (требуется SSR/SSG), уязвимость к ошибкам в клиентском коде (ошибки JS могут полностью «сломать» приложение), зависимость от производительности устройства пользователя.
SPA доминирует в корпоративных приложениях (CRM, ERP, таск-трекеры), редакторах, мессенджерах — там, где интерактивность и скорость реакции важнее, чем индексация контента.

SSR (Server-Side Rendering) — гибридный подход, при котором HTML генерируется на сервере при каждом запросе, как в MPA, но с использованием фронтенд-фреймворка (React, Vue, Angular). Сервер исполняет тот же JS-код, что и браузер, и возвращает полностью готовую HTML-страницу с встроенным состоянием. После загрузки клиентский JS «оживляет» страницу (процесс называется hydration), подключая обработчики событий и переходя в SPA-режим.
Преимущества: быстрая отрисовка первого экрана, улучшенная SEO-индексация (поисковые роботы получают готовый HTML), доступность для пользователей с отключённым JS.
Недостатки: повышенная нагрузка на сервер, увеличение времени TTFB (Time To First Byte), сложность синхронизации состояния между сервером и клиентом, риск несоответствия при гидратации (hydration mismatch).
SSR применяется в медиа-ресурсах, интернет-магазинах, лендингах — там, где важны видимость в поиске и восприятие скорости.

SSG (Static Site Generation) — предварительная генерация HTML-файлов во время сборки. При каждом изменении контента (публикация статьи, обновление товара) запускается процесс, который запрашивает данные у API или CMS, рендерит все страницы во фронтенд-фреймворке и сохраняет результат как статические файлы. Эти файлы затем размещаются на CDN.
Преимущества: максимальная скорость отдачи, минимальная нагрузка на сервер, высокая безопасность (нет исполняемого кода на сервере), идеальная SEO-оптимизация.
Недостатки: невозможность персонализации без клиентского JS, задержка обновления контента (требуется повторная сборка), не подходит для данных, изменяющихся чаще, чем частота сборок.
SSG широко используется в документации (включая Docusaurus), блогах, портфолио, landing-страницах.

ISR (Incremental Static Regeneration) — развитие SSG, введённое Netlify и Vercel. Позволяет обновлять отдельные страницы в фоне, после того как они уже отданы как статические. При первом запросе страница может отдаваться из кэша (старая версия), параллельно запускается регенерация; при следующем запросе — уже новая. Это сочетает преимущества статики (скорость, безопасность) с возможностью частичного обновления без полной пересборки.
ISR особенно эффективен для крупных сайтов с редко меняющимся контентом (каталоги, справочники), где полная пересборка занимает значительное время.

Выбор архитектуры не является однократным решением: современные фреймворки (Next.js, Nuxt, Remix) позволяют применять разные стратегии на уровне отдельных страниц. Например, главная страница и статьи могут генерироваться статически (SSG), а личный кабинет — рендериться на сервере (SSR), а редактор документов — работать как SPA. Такой гибридный подход (иногда называемый partial hydration или islands architecture) становится стандартом для сложных проектов.

Безопасность​

Веб-приложение, по определению, размещается в открытом, ненадёжном окружении — сети Интернет. Это накладывает строгие требования на проектирование: никакая часть клиентского кода не может быть доверенной. Любой JavaScript, CSS или HTML, отправленный браузеру, может быть изменён пользователем. Следовательно, безопасность должна обеспечиваться на уровне сервера и протоколов.

CORS (Cross-Origin Resource Sharing) — механизм, регулирующий, какие внешние домены могут отправлять запросы к API. Браузер блокирует предварительные (preflight) запросы (OPTIONS), если сервер не указал в заголовках разрешение (Access-Control-Allow-Origin, Access-Control-Allow-Methods). CORS защищает пользователя от вредоносных сайтов, пытающихся использовать его авторизацию для доступа к другим сервисам. Он не защищает сервер — злоумышленник может отправить запрос напрямую, минуя браузер. Поэтому CORS должен дополняться серверной валидацией.

CSRF (Cross-Site Request Forgery) — атака, при которой вредоносный сайт заставляет браузер пользователя отправить авторизованный запрос к целевому приложению (например, перевод денег) без его ведома. Защита строится на нарушении автоматизма: сервер требует специальный токен (CSRF-token), который:

  • генерируется при загрузке формы или страницы;
  • передаётся в теле запроса (не в куках и не в заголовках по умолчанию);
  • проверяется на соответствие сессии.

Современные SPA часто используют аутентификацию через Bearer-токены в заголовке Authorization, что делает CSRF менее актуальным (поскольку токен не хранится в куках и не отправляется автоматически), но не отменяет необходимости защиты для форм на SSR-страницах.

XSS (Cross-Site Scripting) — внедрение и исполнение произвольного JavaScript в контексте чужого сайта. Возникает при некорректной обработке пользовательского ввода: если данные, введённые пользователем А, отображаются пользователю Б без санитизации, А может внедрить вредоносный скрипт (например, <img src=x onerror="stealCookies()">).
Защита многоуровневая:

  • экранирование (escaping) на стороне сервера при вставке данных в HTML (заменять < на &lt;);
  • Content Security Policy (CSP) — HTTP-заголовок, ограничивающий источники выполнения скриптов, стилей, изображений (script-src 'self' запрещает inline-скрипты и внешние домены);
  • отказ от innerHTML и dangerouslySetInnerHTML в пользу безопасных методов (textContent, JSX-транспиляция).

Аутентификация и сессии — критически важный элемент. Современные приложения избегают хранения сессий в обычных куках без флагов:

  • HttpOnly — запрещает доступ к куке из JavaScript (защита от XSS);
  • Secure — передача только по HTTPS;
  • SameSite=Strict или Lax — предотвращение отправки куки в кросс-сайтовых запросах (частичная защита от CSRF).

Альтернативой являются JWT (JSON Web Tokens), передаваемые в заголовке Authorization: Bearer <token>. Они не зависят от кук, но требуют дополнительных мер: короткий срок жизни, хранение в HttpOnly куке всё равно (для защиты от XSS), механизм отзыва (через блэклист на сервере).

Важный принцип: все проверки прав доступа (авторизация) должны выполняться на сервере при каждом запросе. Даже если фронтенд «скрывает» кнопку удаления для неавторизованного пользователя, сервер обязан проверить роль при попытке вызова DELETE /api/resource/123.

Производительность​

Производительность веб-приложения измеряется не абстрактными метриками, а конкретными этапами жизненного цикла открытия страницы. Ключевые показатели (Core Web Vitals) определены Google и отражают субъективное восприятие пользователя:

  • LCP (Largest Contentful Paint) — время до отрисовки самого крупного видимого элемента (изображение, заголовок). Зависит от TTFB, размера HTML, скорости загрузки ресурсов, блокировок CSS/JS. Оптимизация: SSR/SSG, оптимизация изображений, приоритизация критических ресурсов.

  • FID (First Input Delay) / INP (Interaction to Next Paint) — задержка между первым взаимодействием (клик, нажатие) и реакцией интерфейса. Высокое значение говорит о блокирующем основном потоке (long tasks). Оптимизация: code splitting, вынос тяжёлых вычислений в Web Workers, оптимизация фреймворков (React.memo, useCallback).

  • CLS (Cumulative Layout Shift) — совокупный сдвиг макета: внезапное перемещение элементов при загрузке (из-за отсутствующих размеров изображений, динамической вставки баннеров). Оптимизация: указание width/height у изображений, резервирование места под рекламу, избегание вставки контента сверху.

Технические приёмы повышения производительности:

  • Critical Rendering Path Optimization — минимизация количества и размера ресурсов, блокирующих первую отрисовку. Включает: инлайн критических CSS, асинхронную загрузку JS (async, defer), отложенный импорт несущественных модулей.

  • Code Splitting — разделение JS-бандла на части, загружаемые по требованию (например, по маршруту или при взаимодействии). Реализуется через динамические import() в Webpack, Vite, Rollup. Позволяет сократить объём первоначальной загрузки на 50–80 %.

  • Hydration Strategies — в SSR/SSG приложениях «оживление» (hydration) всего DOM сразу может блокировать основной поток. Современные подходы:

    • progressive hydration — поэтапное подключение компонентов по мере появления в области просмотра;
    • selective hydration — первоочередное подключение интерактивных элементов (кнопки, поля ввода);
    • resumability (Qwik) — сохранение состояния рендеринга на сервере, чтобы клиент продолжил с того же места, без повторной инициализации.

  • Caching Strategies — грамотное использование HTTP-кэширования (Cache-Control, ETag, Last-Modified) и клиентских хранилищ (Service Worker, Cache API) позволяет сократить повторные загрузки до нуля. Например, Service Worker может кэшировать index.html с stale-while-revalidate, обеспечивая мгновенную загрузку даже при отсутствии сети.

Современные направления​

Развитие веб-платформы не останавливается на SPA и SSR. Появляются технологии, расширяющие границы возможного.

WebAssembly (Wasm) — бинарный формат выполнения, поддерживаемый всеми современными браузерами. Позволяет запускать код, скомпилированный из C/C++, Rust, Go, с производительностью, близкой к нативной. Применяется для:

  • тяжёлых вычислений (обработка видео, 3D-рендеринг, криптография);
  • портирования десктопных приложений (Figma, AutoCAD Web);
  • выполнения кода в изолированной среде (sandbox для плагинов).

Wasm не заменяет JavaScript, а дополняет его: JS остаётся «клейкой лентой», управляющей вызовами и DOM-взаимодействием, а Wasm — вычислительным ядром.

Progressive Web Apps (PWA) — набор практик, превращающих веб-приложение в нечто, приближенное к нативному:

  • работоспособность офлайн (через Service Worker);
  • установка на домашний экран (manifest.json);
  • пуш-уведомления (Push API, Notifications API);
  • доступ к некоторым аппаратным возможностям (геолокация, камера, Bluetooth).
    PWA не требует публикации в магазинах, обновляются автоматически, но ограничены в доступе к системным API по соображениям безопасности.

WebContainers — технология, позволяющая запускать полноценный Node.js-стек внутри браузера, на основе WebAssembly и изолированных процессов. Позволяет:

  • выполнять сборку проектов (Vite, Webpack) на клиенте;
  • запускать серверные процессы (Express, Fastify) в изолированном окружении;
  • обеспечивать полную изоляцию среды разработки (как в CodeSandbox, StackBlitz).

Это знаменует переход от «браузер как клиент» к «браузер как операционная система», где слой сервера может быть полностью элиминирован для определённых сценариев (обучение, прототипирование, локальная обработка).